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Preface 


The purpose of this guide is to assist the student of an introductory 
course in database system in conjunction with the author’s text Introduction 
to Database Systems. It is suggested that the student try the exercises given 
a the end of the chapters before consulting the solutions given here and 
compare their the solutions. 


The organization of this guide follows the suggested plan 
diagrammed in the preface of the text. Solutions for selected end of 
chapter exercises are given. The exercises in some of the chapters are of a 
general nature and their solutions are not included. The chapters on File 
organization and Higher order normal forms would not be covered in many 
undergraduate syllabus: and Chapters 8 and 9, are often considered 
obsolete, and not covered in these courses. Hence the solution to the 
exercises in these chapters are not provided. 


Bipin C. DESAI 


1. Basic Concepts 


Objectives: This chapter introduces the student to the following 
concepts and gives overview of a DBMS system. 


Concept of modelling for database 

Concept of entities and their attributes and keys 
Concept of relationship and their attributes 
Concept of data integration for sharing 

Three level architecture for a database system 
Mapping between levels and data independence 
Components and structure of a DBMS 

Pros and cons of a DBMS 


Solution to selected exercises 


2. Data Models 


Objectives: This chapter introduces the student to the following 
concepts and gives and overview of different database models. 


Concept of data associations and introduction of the concept of 
functional dependency 

Concept of relationships among entities 

Entity-Relationship model and its use 

Concept of aggregation, generalization and specialization 

Introduction to relational, network and hierarchical models 

Comparison of these models. 


In this chapter we look at the method of modelling entities, and the 
interrelations of these entities. We introduce the concept of association 
amongst various attributes of an entity and the relationships among entities. 
We, also, introduce the data models used in database applications. They 
differ from each other in the methods used to represent the relationships 
among entities. 


Solution to selected exercises 


3. FILE ORGANIZATION 


Objectives: This is an optional chapter and may be skipped in most 
of the programs where, a course in File Systems is a prerequisite or co- 
requisite to the course in database systems. The chapter introduces the 
student to the following concepts and gives overview of file systems. 


.Characteristics of storage devices 

.The components of a file 

.Basic file access and primary key retrieval 
Serial, Sequential, and Index-Sequential Files 
.Concept of Multi-level Indexing 

.Concept of hashing and Direct File organization 
.Extensible Hashing 

Secondary Key Retrieval 

Inverted Index Files 

-Multi-list Files 

Cellular Files 

-Ring Files 

.Tree Structured files 

. B+-tree and B-tree and their comparison 


In this chapter, we focus on a number of methods used to organize 
files and the issues involved in the choice of a method. File organization 
deals with the structure of data on secondary storage devices. In designing 
the structure the designer is concerned with the access time involved in the 
retrieval of records based on primary or secondary keys, as well as the 
techniques involved in updating data. We discuss the following file 
organization schemes: sequential, index sequential, multi-list, direct, 
extensible hashing, and tree structured. The general principles involved in 
these schemes are presented, while not delving into the implementation 
issues under a specific operating system. 


Solution to selected exercises 


3.3. (a) Each entry in the bucket will have a key value of 10 bytes and 
block address of 5 bytes for a total of 15 bytes. This means that we can 
have a maximum of 66 entries in a block of a bucket. Since there are 1000 
buckets. each bucket has 1000 entries and the total number of blocks per 
bucket is 16. On the average half of these buckets have to be accessed to 
find an existing record and the actual record would require another access 
for a total of 9 accesses per record. 


3.3. (b) In the index sequential organization, there would be one entry per 
file block. Each file block contains 5 records, hence there will be a total of 
200000 index entries. Since each index block could have 66 entries, the 
total number of index blocks is 3031. A binary search will require 12 
accesses in the index block followed by an access to the file for the actual 
record, for a total of 13 accesses. 


In the index sequential organization, there would be one entry per 
file block. Each file block contains 5 records, hence there will be a 
total of 200000 index entries. Since each index block could have 66 
entries, the total number of index blocks is 3031. A binary search 
will require 12 accesses in the index block followed by an access to 
the file for the actual record, for a total of 13 accesses. 


3.3. (c) Each index (internal) node of the B+-tree index would be able to 
contain a maximum of 66 key values and 67 pointers. We assume that the 
B+-tree is a dense index, hence each key value is in the leaf node. The 
number of lowest level internal nodes is 15152. At the next level there will 
be 230 nodes. Then on the following level, we would have 4 nodes and 
there would be one node at the root level. The total number of nodes is 
therefore, 1 + 4 + 230 + 15152 = 15387, and the height of the tree is 4. 


3.3. (d) The number of lowest level internal nodes is 30304. At the next 
level there will be 919 nodes. On the succeeding level, we would have 28 
nodes and there would be one node at the root level. The total number of 
nodes is therefore, 1 + 28 + 919 + 30304 = 31252, and the height of the tree 
is still 4. 


3.4. (a) Since there are ten million records and 10000 buckets, the number 
of entries per bucket is 10,000,000/10,000 = 1000. Since this represents 
half the capacity of the bucket, each bucket is to have a capacity for 2000 
entries. Each entry consists of a key value and a block address and requires 
10 bytes. Hence, the size of the bucket is 20,000 bytes, or, it requires 2 
physical blocks. Since hashing is used, the first block access would find the 
correct bucket and the next access would find the appropriate record. 


3.4. (b) The number of data blocks is given by: 


2*10*106*100/10,000 = 2* 10s 
Since there is an entry in the index for each block, the number of blocks 
needed for this level of indexing is given by: 

2*105*10/10,000 = 200 
The binary search in these number of blocks would need 8 accesses 
followed by an access to one data block for a total of 9 accesses. 


3.4. (c) The number entries in the leaf nodes is 10*106 and assuming a 
leaf node contains a key value and a block address, there will be 1000 
entries per leaf node and 10,000 leaf nodes. This is also the number of 
entries in the lowest level internal node of the B+-tree. Assuming the nodes 
are full, there would be 200 nodes at this level and one node at the root 
level. The height of the tree is two. The number of disk accesses required, 
is two for the root and the internal node of the B+-tree combined, followed 
by one for the leaf node, as well as one for the data block containing the 
actual record. 


3.5. (a) With a block size of 5,000 bytes and a record size of 200 bytes, the 
blocking factor is 25. Hence, the total number of blocks in the file would be 
1,000,000/25 = 40,000. 


Time to read each block = 25*10-3 + 5,000/(100 * 103s) 
= 75* 10-3 sec 
Time to process the tape = 40,000*75*10-s sec 
= 3,000 sec 


3.5. (b) With a block size of 50,000 bytes Title and a record size of 200 
bytes, the blocking factor is 250. Hence, the total number of blocks in the 
file would be 1,000,000/250 = 4,000. 


Time to read each block = 25*10-3 + 50,000/(100 * 103s) 
= 525* 103 sec 


Time to process the tape = 4,000*525*10.s sec 
= 2,100 sec 


3.7. 
Since 80% of the tape is to be used to record data, each block would be of a 


2.4 inch length giving a blocking factor of 120. 


3.11. (a) 


Directory 


» 
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3.11. (b) 
File 


MICROSLAW SMITH F 
PASSASLO JONES A 
PRONOVOST WAGNER B 


LOANNIDES ACIAN R 
MACIOCIA BROST A 
CHO BYUNG JONES A 


CANNON JONES A 


BERGEROM JONES A 
ABOND 


HAMMERBELL 
LANGEVIN 
PELLERIN 


ROBERT 
SHARPE 
PETIT 


For Dept = COMP we access record 1, and make the following entry in the 
DONTAG list: <record 1, Advisor = Smith F, 10>; <record 1, Status = F2, 
6>. We find the next record for Dept = COMP list to be 8 and access this 
record. No entries are made in the DONTAG list. The next record to be 
accessed for Dept = COMP list is 10. Here we make the following entry in 
the DONTAG list: <record 10, Advisor = Smith F, 14>. The next record to 
be accessed for Dept = COMP list is 12. Here we make the following entry 
in the DONTAG list: <record 12, Status = F2, > The last record to be 
accessed for Dept = COMP list is 13. No entries are made in the 
DONTAG list. At the end of traversing this list, the DONTAG list contains 
the following entries: 


<record 1, Advisor = Smith F, 10> 
<record 1, Status = F2, 6> 

<record 10, Advisor = Smith F, 14> 
<record 12, Status = F2, > 


Now the list for Status = F2 is to be traversed. The first record from the 
directory is found to be 1. Before accessing this record, the DONTAG list 
is consulted and it is found that there is an entry in it for this record which 
also indicates that the next record for Status = F2 to be 6. Since from the 
DONTAG list we find that the record has not been previously accessed, we 
access it. Processing this record we find that the DONTAG list does not 
have to be updated and we discover, further, that the next record having the 
same value for Status is 12. However, the DONTAG list entry <record 12, 
Status = F2, > indicates that this record was already accessed and there are 
no further records in this list. 


Now the list for Advisor = Smith F is to be processed starting with the 
record 1. Consulting the DONTAG list, we conclude that this record was 
already accessed and that the next record in this list is 10. Again the 
DONTAG list tells us that this last record was already processed earlier and 
that we now have to access and process record 14. Since there is no entry 
for record 14 in the DONTAG list, we access it and find that the next 
record to be accessed is record 15. This last record is the tail of the list and 
we have accessed all records satisfying the query. 


3.11. (c) 


Directory with an entry per cell 


WAGNER B/3,9,12 


Cellular File 
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3.16. File before modifications: 


cyl. Sectors 
41 1 2 3 4 
Surf. 
00 8 8=6 Tr. Index Al,A4 As,Ag,Ag Alo,A 
107413 
Me 417/418 20 A28,A29 A30,A31,A36 
42443 Ag5,Ag6,Agg A51,A52,As6 A59,A61 
475¢476 A478 A79,Ago Ag3 89,A9] 
“4 93494 A96,Ag8 ‘00 A120" 125 


File after modifications 


cyl. Sectors 


41 1 2 3 4 

Surf. 

00 Tr.Index A ,,A2,A3 As,A Ag,Aj0,A 3 

Ol Ai7,Aig A20 Ads, 429 A30,431,433 
O2 AgiAg2,Ag3 Ags, Agg,Agg A51,A52,A54 456,459,460 
03 A75,A76,A7g A79,Ag0 Ag2,Agq Agg,A91 

04 Ao3 Aa A95,A96,Ag8 A100 A120, 122+A124 
O05 A34,*A36, *Ag1 A125 - 


Track index after file modifications 


4. The Relational Model 


Objectives: This chapter introduces the student to the Relational 
data model and relational algebra and calculus. The following concepts are 


introduced: 


Concept of attributes, domains, tuples, and relations 
Operation on relations 

Integrity rules 

Relation Schemes 

Representing relations 

Relational Algebra and operations 

Relational Calculus 

Tuple Calculus 

Domain Calculus 

Comparison of Relational Algebra and Relational Calculus 


Solution to selected exercises 


4.1. Relations P and Q are as follows: 


4.1.1. Find the projection of Q on the attributes (B,C). 


4.1.2. Find the natural join of P and Q on the common attributes. 
P pa Q 


4.1.3. Divide P by the relation that is obtained by first selecting those tuples 
of Q where the value of B is either b1 or b2 and then projecting Q on the 
attributes (C,D). 


Tle, p?B=b1ve=b22 P+Te p%gebive=b22 


4.2 The relational database scheme is given as: 


PARTS(P#,Name, Colour) 
SUPPLIER(S#,Name,Address) 
CAN_SUPPLY(S#,P#,Quality) 
SUPPLY (S#,P#,Price,Qty) 


The relations CAN_SUPPLY and SUPPLY contain foreign keys 
S#, P#. Presence of foreign keys requires the maintenance of referential 
integrity. The addition, deletion and modification of tuples must ensure this 
integrity. 


TH SUPPLIER. S#, SUPPLIER Name, SUPPLIER.Address, SUPPLY .Price) (X) 


where X is given by 
TroarTs.P#7PARTS.Name='botts! (PARTS) bd SUPPLY e< SUPPLIER 


{s|3t,u,v(teSUPPLIER ~ u€PARTS a veSUPPLY 
a u[Name] = 'bolts' 

t(S#] v[S#] 

uf{P#] = v[P#] 

s(S#] t(S#] 

s(Name}] = t[Name) 

s[{Price] = v{Price}]) } 


ee oe DM eh 22 


4.3.(a) 


4.3 (b) 
Let Y = PARTS | SUPPLY XSUPPLIER 


Now find the unary relation R containing the S# of suppliers who supply 
bolts costing less than $0.01. 


R = JU(SUPPLIER.S#)(O(PARTS.Name='bolts' A SUPPLY.Price<.01)Y 


The details of the parts supplied by these SUPPLIERs is obtained as 
follows: 
Jt(PARTS.P#,PARTS.Name,PARTS.Colour,R.S#)(OCAN_SUPPLY. Quality > xZ) 


where Z is the relation obtained by a natural join of R, CAN_SUPPLY, and 
PARTS. 


{x]3 r,s,t(r € SUPPLIER « s € PARTS ~ t € SUPPLY 
a t{Price}] < 0.01 

s({Name) = 'bolts' 

s[P#] = t[P#] 

r[S#]) = t[S#} 

3 u,v(u € CAN_SUPPLY a v € PARTS 

u(S#] = r[S#) 

u(Quality] > x 

u(P#)] = v(P#) 

x(S#] = u[{S#} 

x(P#}] = v[P#} 

x(Name) = v[Name} 

x[(Colour] = v[Colour))) ) 


Le ee ee eee ae. ae 


4.4. (a) 
JUSHENROLL M(Ocreact prof='smith'V TEACH.Prof='Jones TEACH) 


{s_|de,t(e EENROLL A t € TEACH A (t[Prof] = 'Smith' V t[Prof] = 


‘Jones') 
A e[C#] = t[C#] A e[Section] = t[Section] A s[S#] = e[S#]} 


4.4. (b) 
nS#(ENROLL TEACH | ADVISE) 


{s_lde,t,a (e € ENROLL A t € TEACH Aa € ADVISE A e[C#] = 
t[C#] A 


e[Section] = t[Section] A t[Prof] = a[Prof] A a[S#] = e[S#] A 
s[S#] = a[S#]} 


4.4. (c) 
Let TEACH1 and TEACH2 be copies of the relation TEACH. 


Let R= TEACHI1 X TEACH2, then 
S=O(TEACH1.Prof=TEACH2. Prof\TEACH1.C#=TEACH2. C# 
ATEACHI1.Section# TEACH?2.Section)(R) 


The required response is given by 7ZTTEACH1.ProfS 


{pLdt1, t2 (t1 € TEACH A t2 € TEACH A tl1[C#] = t2[C#] A 
t1 [Section] = t2[Section] 


A t1 [Prof] = t2[Prof] /\ p[Prof] = t2[Prof]) 


4.4. (d) 
A way to tackle this rather complex query is to break it down into a 
set of simpler queries and then deal with them individually. This 
approach is illustrated below: 


- Find the set of courses that Mr. Doe has passed: 
PASS(C#) 


- Find the courses that Mr. Doe cannot do: 
CANNOTDO(C#) 


- Subtract the above set of courses from the set of all courses to get 
those that he can do. CANDO(C#) 


- Some of these may have been already completed. Therefore, to 


find the required response subtract from the above set of courses 
that can be done by Mr. Doe, those that he has passed. 


- Find the set of courses that Mr. Doe has passed: PASS(C#) 


PASS(C#)=70C#((OGRADES.Grade = ’F’ GRADES) X(OSTUDENT. Sname='John 
Doe'STUDENT)) 


-The courses being offered are given by the projection of TEACH on 
C#. 


-To find the courses that Mr. Doe can do we find those courses for 
which he has the required prerequisite. This is obtained by 
performing the Cartesian product of the courses being offered with 
PASS. The attribute of PASS being renamed Pre_C#. Let us call this 
relation HAS_PRE_REQ(C#, Pre_C#) 


HAS_PRE_REQ(C#, Pre_C#)=(7TTEACH.C#TEACH) X 
PASS[Pre_C#] 


Now the courses that Mr. Doe cannot do is given by: 


CANNOTDO(C#) = 71C#(PRE_REQ - HAS_PRE_REQ) 
Courses he can do is then given by: 
CANDO(C#) = (1C#TEACH) - CANNOTDO 


Subtracting the courses already completed, we get the courses for 
which Mr. Doe can now enrol: 


CAN_ENROLL(C#) = CANDO(C#) - PASS(C#). 


4.5. (a) Let us first find the relation X as follows: 
X = o(Conductor='Letitia Melody')Y 


where Y (Conductor, Composition, Player, nstrument) is given as : 

Y= conducts X requires X plays 

Then the list of players and their instruments that can be part of the 
orchestra when Letitia Melody conducts is given by: 


(Player, Instrument)X 


{z Aor,p(c € conducts A r © requires A p © plays 


A c[Conductor] = 'Letitia Melody' A c[Composition] = 
r[Composition] 

A r[Instrument] = p[Instrument] A z[Player] = p[Player] A 
z[Instrument] = p[Instrument])} 


Note: The schema of z define in the TRC query, 


4.5 (b) Let TEMP be the relation defined below: 
TEMP = OConductor= ‘Letitia Melody'conducts 


Then the players who like the composition they are likely to play is 
given by: 


JUlikes.Player(requires X| plays X likes | TEMP) 


{x_ldc,r,p,l(¢c © conducts © r € requires A p € plays Al © 
likes 
/\ c[Conductor] = 'Letitia Melody' A c[Composition] = 


r[Composition] A 1[Player] = x[Player] 
A c[Composition] = |[Composition] / r[Instrument] = 
pLInstrument] A \[Player] = p[Player] )} 


4.7 (a) Select tuples from rell such that the attribute B has either the value 
Bi or Bz. 
4.7 (b) oB='B1'VB='B2\(rell1) 


4.1(c) {tt Erell A (t[B] ='B.' V t[B] ='B2)} 


4.10. "Get complete details of employees working on a Database project." 


{sls € employee A du tt € project /\ t[Project_Name] = 
'Database' 

Au E assigned_to A u[Project#] = t[Project#] A 
s[Emp#] = u[Emp#])} 
The above can be written using the identity AxA(x) = AV x(A(x)) as 
follows: 


{s ls © employee A =Vu,t (t ¢ project V tL[Project_Name] + 
‘Database’ 

V u Eassigned_to V u[Project#] = t[Project#] V 
s[Emp#] = u[Emp#])} 
The query "Get complete details of employees working on all Database 
projects" can be expressed as follows: 


{s |s © EMPLOYEE AVt(t & PROJECT \V/ t[Project-Name] = 
'Database' 


VV ducu © ASSIGNED _TO A u[Project#] = t[Project#] A s 
[Emp#] = u[Emp#])} 


The above can be written using the negating both of the identity 
dxac@ = -Vx(-AGy) 
ie., -(AxA@)) = -(--'Vx(-AG0)) which is: 
Vx(A@)) = 7dx(-A())as follows: 


{sls © employee A TAt(-{t € PROJECT \V t[Project-Name] 
* 'Database' 
V du(u € ASSIGNED_TO A u[Project#] = t[Project#] As [Emp#] 
= u[Emp#])}] 


{s ls © employee A ast € project / t[Project_Name] = 
'Database' 


A774 u (u Eassigned_to A u[Project#] = t[Project#] 
A s[Emp#] = u[Emp#])} 


"List the complete details of employees working on both COMP353 and 
COMP354." 


{s(]s € employee A dul,u2 (ul € assigned_to 

A u2 € assigned_to A ul[Emp#] = u2[Emp#] 

A s[Emp#] = ul[Emp#] A ul[Project#] = 'COMP353' 
A u2[Project#] = 'COMP354')} 


Interchanging the quantifiers using Ax A(x) = AV x(A(x)) we get: 


{s L|s € employee A =Vul,u2 (ul ¢ assigned_to 

V u2 € assigned_to V ul[Emp#] + u2[Emp#] 
Vs[Emp#] ~ ul[Emp#] V ul[Project#] = 'COMP353' 
V u2[Project#] + 'COMP354')} 


Exercise: modify the above query to read "List the complete details of 
employees working on either 'COMP353' or COMP354 or both." 


"Get employee numbers of employees, excluding employee 107, who 
works on at least one project that employee 107 works on". 


{t[Emp#]_] t € assigned_to A As (s € assigned_to A s[Emp#] 
107 


A duu é assigned_to A s[Project#] = u[Project#] 
A ulLEmp#] ~ 107 A tlLEmp#] = ulEmp#])} 


Interchanging the quantifiers using AxA(x) — AV x(3A(x)) we get: 


{t[Emp#]|! t © assigned_to A aVs (s € assigned_to V 
s[Emp#] + 107 

V -~du(u € assigned_to A s[Project#] = u[Project#] 

A ulLEmp#] ~ 107 A tlLEmp#] = ulEmp#])} 


"Get employee numbers of employees who do not work on project 
COMP453". 
{ t[Emp#]\/ t © assigned_to A 

=dutu € assigned_to A u[Project#] = 'COMP453' A 
tlLEmp#] = ul[Emp#])} 
Interchanging the quantifiers using AxA(x) = aV x(AA(x)) we get: 


{ t[Emp#]l t © assigned_to A Vu (u € assigned_to 
V ul[Project#] = 'COMP453' V tlEmp#] =~ ul[Emp#])} 


"Compile a list of employee numbers of employees who work on all 
projects." 


{ tlEmp#]_! t © assigned_to A 

Vp(p € PROJECT — Ju( u € assigned_to 

A p[Project#] = u[Project#] A t[Emp#] = 
ulEmp#]))} 


This can be re-written f — g can be replaced by =f V g: 


{ tlEmp#]_| t © assigned_to A 
Vp(p € PROJECT V Ju( u € assigned_to 
A p[Project#] = u[Project#] 
A t[Emp#] = u[Emp#]))} 


Interchanging the quantifiers using Vx(A(x)) = =4x(-A(x)), we 
get: 
{ tlEmp#]_ t © assigned_to A 

=A p(p € PROJECT A ~du( u € assigned _to 

A p[Project#] = u[Project#] A tlLEmp#] = 
u[Emp#]))} 


"Get employee numbers of employees, not including employee 107, who 
work on at least one project that employee 107 works on". 


{ t[Emp#]\/ t © assigned_to A 


ds,u (s € assigned_to A u € assigned_to 
A s[Project#] = u[Project#] A s[Emp#] = 107 
A t(Emp#] # 107 A t[Emp#] = u[Emp#])} 


After interchanging the quantifiers, we get: 


{ t[Emp#]\/ t é assigned_to A 


aVs,u (s # assigned_to \ u ¢ assigned_to 

V s[Project#] + u[Project#] V s[Emp#] = 
107 

V tlEmp#] = 107 V tlEmp#] =~ ulEmp#])} 


4.12 (a) Acquire details of the projects for each employee by name. 
JtEMPLOYEE.EmpName,PROJECT.Project#,PROJECT.Project_Name, PROJECT. Cheif., 


Here the relation X is given as: ASSIGNED.TO | EMPLOYEE X 


PROJECT 


4.12 (b) Compile the names of projects to which employee 107 is 
assigned. 

Let X be the relation as : 

(GEMPLOYEE.EmpN# = 107(ASSIGNED_TO)) DX] PROJECT 


Then the project names are obtained as: tPROJECT.Project_Name(X) 


4.12 (c) Access all employees assigned to projects whose chief architect is 
employee 109. 


The required employee numbers are given by: 
mEMPLOYEE.Emp#((ASSIGNED_TO) PX (x)) 


where the relation X is given by: 


X = JUPROJECT.Project#(OPROJECT.Cheif_Architect= 109(PROJECT)) 


4.12 (d) Derive the list of employees who are assigned to all 
projects where employee 109 is the chief architect. 


The list is given by ASSIGNED_TO ~ X, where X is obtained as 
follows: 


X = JU.Project#(OCheif_Architect = 109(PROJECT)) 


4.12 (e) Get all project names to which employee 107 is not 
assigned. 

Let X be given by: 

X = JtProject#(OEmp# = 107(ASSIGNED_TO)) 

and let Y. the project numbers where 107 is not assigned is given 
by: 

Y = mProject#PROJECT - X 

Then the required response is given by Z where Z is: 


Z = mPROJECT.Project Name(PROJECT [XI Y) 


4.12 (f) Get complete details of employees who are assigned to 
projects not assigned to employee 107. 


Let X be given by: 


X = JUPROJECT.Project#(OASSIGNED_TO.Emp# = 107(ASSIGNED_TO)) 
and let Y be given by: 


Y = ASSIGNED _TO DX (JUPROJECT.Project#PROJECT - X) 
Then the requires response is given by: 


JUEMPLOYEE.Emp#EMPLOYEE.EmpName(EMPLOYEE [xX] y) 


4.13 (a) Acquire details of the projects for each employee by name. 
{e[EmpName],p L] 4 e,a,p(e & EMPLOYEE /A\ a © ASSIGNED_TO 


A. p © PROJECT A alProject#] = p[Project#] /\ alEmp#] = 
e[Emp#]} 


4.13 (b) Compile the names of project to which employee 107 is 
assigned. 

{p[Project_Name] |] 4 a,p (a © ASSIGNED_TO A. p © PROJECT 
A alEmp#] = 107 A a[Project#] = p[Project#] )} 

4.13 (c) Access all employees assigned to projects whose chief 
architect is employee 109. 

{a[Emp#] |] 4 a,p (a © ASSIGNED_TO A p © PROJECT 

A p[Cheif_Architect] = 109 A p[Project#] = a[Project#] )} 


4.13 (d) Derive the list of employees who are assigned to all 
projects where employee 109 is the chief architect. 
{tlEmp#] Ll t © ASSIGNED_TO A VW p(p © PROJECT V 
p[Cheif_Architect] + 109 

V da(a € ASSIGNED_TO A p[Project#] = a[Project#] 
A tlEmp#] = alEmp#] ))} 


4.13 (e) Get all project names to which employee 107 is not 
assigned. 

{ p[Project_Name] || p € PROJECT A “da (a © ASSIGNED_TO 
A p[Project#] = alProject#] A al[Emp#] = 107 )} 

4.13 (f) Get complete details of employees who are assigned to 
projects not assigned to employee 107 

{elle © EMPLOYEE Ad el,a,p (e1© EMPLOYEE A a © 


ASSIGNED_TO 

A p © PROJECT A e[Emp#] = e1[Emp#] A el[Emp#] = alEmp#] 
A p[Project#] = a[Project#] \ -Eal(al € ASSIGNED_TO 

A al[Project#] = p[Project#] A alEmp#] = 107 ))} 


4.14 (a) Acquire details of the projects for each employee by name. 
{<m,p,n,c> || del,pl(<el,m> € EMPLOYEE A <pl,el> € 
ASSIGNED_TO 

A <pl,n,c> € PROJECT A p = pl)} 

4.14 (b) Compile the names of projects to which employee 107 is 
assigned. 

{<n> _ dp,e,pl,c(<p,e> © ASSIGNED_TO 

A <pl,n,c> € PROJECT A p = pl Ae = 107)} 

4.14 (c) Access all employees assigned to projects whose chief 
architect is employee 109. 


{<e>Ud p, n,c (<p,e> € ASSIGNED_TO 
A <p,n,c> © PROJECT Ac = 109)} 


4.14 (d) Derive the list of employees who are assigned to all 
projects where employee 109 is the chief architect. 


{<e> V p,n,c(<p,n,c> ¢€ PROJECT Vc = 109 

V i pl(<pl,e> € ASSIGNED_TOA p = p1 )))} 

4.14 (e) Get all project names to which employee 107 is not 
assigned. 

{<n> lL) 4d p,c (<p,n,ce> € PROJECT 

A 4 pl,e(<pl,e> € ASSIGNED_TO A pl = pAe = 107 )} 


4.14 (f) Get complete details of employees who are assigned to 
projects not assigned to employee 107. 

{ <em> |! 4d p,n,c,pl,el(<esm> € EMPLOYEE 

A <p,n,c> € PROJECT 

A (<pl,el> € ASSIGNED_TO Ae = el Apl =p 


A ( 73p2,e2(<p2,e2> € ASSIGNED TO 
A p2 = pAe2 = 107 ))} 


5. Relational Database 
Manipulation 


Objectives: This chapter introduces the student to the commercial 
data manipulation languages. We look at the main features of SQL, 
QUEL, and QBE and illustrate their usage. It is normal to cover 
details of SQL, the most common of these languages. In addition, 
some versions of QBE are also implemented in many commercial 
DBMSs and therefore the student should be familiarized with its 
concepts. The concept of using SQL and QUEL embedded in HLL is 
presented too. A comparison of SQL and QUEL with their 
shortcomings is included. 


The following features of SQL are discussed: 


Data definition facilities: create table, alter table, create index, drop 
table, drop index statements 

Data manipulation facilities: select, delete, insert, and update 
statements 

Method of specifying predicates and joins in SQL 

Use of arithmetic and aggregate operators 

Method of specifying joins in SQL 

Nested queries and manipulating sets in SQL 

Specifying quantifiers in SQL 

Creating views in SQL 


The following features of QUEL are discussed: 


Data definition facilities: create, index, modify, and destroy 
statements 

Data manipulation facilities: retrieve, range, delete, append, and 
replace statements 

Method of specifying predicates and joins 

Aggregation in QUEL 

Use of temporary relations in QUEL to implement the SQL nested 
query feature 

Creating views in QUEL 

The basic data retrieval, aggregation and update features of QBE 


are discussed: 


Solution to selected exercises 


5.1. SQL 


(a) List all students taking courses with Smith or Jones. 


select S#,Sname 

from STUDENT, ENROLL, TEACH 

where STUDENT.S# = ENROLL.S# and 
ENROLL.Section = TEACH.Section and 
(TEACH.Prof = 'Smith' or TEACH.Prof = '‘Jones') 


(b) List all students taking at least one course that their advisor 
teaches. 


select ADVISE.S# 

from ENROLL, TEACH, ADVISE 

where ENROLL.Section = TEACH.Section and 
TEACH.Prof = ADVISE.Prof and 
ENROLL.S# = ADVISE.S# and 
ENROLL.C# = TEACH.C# 


(c) List those professors who teach more than one section of the 
same course. 
select t1.Prof 
from TEACH t1, TEACH t2 
where t1.Prof = t2.Prof and 
t1.C# = t2.C# and 
t1.Section © t2.Section 
(d) List the courses that student "John Doe" can enrol in, i.e., has 
passed the necessary prerequisite courses but not the course itself. 


As before, this query is resolved by breaking it down into a set of 


simpler queries: 


(i) Find the courses John Doe cannot do, 
(ii) Find the courses John Doe can do, 
(iii) Find courses John Doe can enrol-in. 


(i) Let us first create a temporary relation TEMP1(C#) and store 
the courses that John Doe has passed in it as follows: 


insert into TEMP1 
select C# 
from STUDENT, GRADES 
where Sname = ‘John Doe' and 
Grade ~ 'F' and STUDENT.S# = GRADES.S# 


Now let us find the Cartesian product of the courses offered and the 
courses passed, to find those courses for which he has the necessary 
prerequisites. Save the result into another relation TEMP2(C#, 
Pre_C#). 


insert into TEMP2 
select TEACH.C#, Pre_.C# = TEMP1.C# 
from TEACH, TEMP1 


Now let us find the set of courses that he cannot do and store it into 
the temporary relation TEMP3(C#): 
insert into TEMP3 
select C# 
from PRE_REQ 
where not exists 
(select * 
from TEMP2 
where PRE REQ.C# = TEMP2.C# and 
PRE_REQ.Pre_C# = TEMP2.Pre_C#) 


(ii) Now let us find the courses that John Doe can do and store 
these in a temporary relation TEMP4(C#) as follows: 


insert into TEMP4 
(select C# 


from TEACH) minus 
(select C# 
from TEMP3) 


(iii) Now we can find the courses that he can enrol-in as: 


(select C# 

from TEMP4) minus 
(select C# 
from TEMP1) 


QUEL 
(a) List all students taking courses with Smith or Jones. 


range of s is STUDENT 

range of e is ENROLL 

range of t is TEACH 

retrieve (s.S#, s.Sname) 

where s.S# = e.S# and 
e.C# = t.C# and 
e.Section = t.Section and 
(t.Prof = 'Smith' or 
t.Prof = 'Jones') 


(b) List all students taking at least one course that their advisor 
teaches. 


range of a is ADVISE 

range of e is ENROLL 

range of t is TEACH 

retrieve (a.S#) 

where e.C# = t.C# and 
e.Section = t.Section and 
t.Prof = a.Prof and 
e.S# = aS# 


(c) List those professors who teach more than one section of the 
same course. 


range of tl is TEACH 

range of t2 is TEACH 

retrieve (t1.Prof) 

where t1.Prof = t2.Prof and 
tl.C# = t2.C# and 
t1.Section © t2.Section 


5.2 
conducts (Conductor, Composition) 
requires (Composition, Instrument) 
plays (Player, Instrument) 
likes (Player, Composition) 

SOL 


(a) List the players and their instruments that can be part of the 
orchestra when Letitia Melody conducts. 


select Player, Instrument 

from conducts requires plays 

where conducts.Composition = requires.Composition and 
requires.Instrument = plays.Instrument and 
Conductor = 'Letitia Melody' 


(b) From the above list of players, identify those who like the 
composition they are likely to play. 


select likes. Player 

from conducts, requires, plays, likes 

where conducts.Composition = requires.Composition and 
conducts.Composition = likes.Composition and 
requires.Instrument = plays.Instrument and 
plays.Player = likes.Player 


QUEL 


(a) List the players and their instruments that can be part of the 
orchestra when Letitia Melody conducts. 


range of c is conducts 


range of r is requires 

range of p is plays 

retrieve (p.Player,p. Instrument) 

where c.Composition = r.Composition and 
r.Instrument = p.Instrument and 
c.Conductor = 'Letitia Melody' 


(b) From the above list of players, identify those who would like the 
composition they are likely to play. 


range of c is conducts 

range of r is requires 

range of p is plays 

range of | is LIKES 

retrieve (1.Player) 

where c.Composition = r.Composition and 
r.Instrument = p.Instrument and 
c.Composition = r.Composition and 
c.Composition = |1.Composition and 
c.Conductor = 'Letitia Melody' 


QBE 


(a) List the players and their instruments that can be part of the 
orchestra when Letitia Melody conducts. 


CONDUCTS Conductor |_| Composition 


Letitia Melody |! CO 


REQUIRES Composition || Instrument 


P.PL P.IN 


(b) From the above list of players, identify those who would like the 
composition they are likely to play. 


CONDUCTS Conductor || Composition 


Letitia Melody |! CO 


REQUIRES Composition || Instrument 


LIKES || Player || Composition 


5.3 
Acquire details of the projects for each employee by name. 


select Emp#, EmpName, Project_Name 

from ASSIGNED_TO, EMPLOYEE, PROJECT 

where ASSIGNED _TO.Project# = PROJECT.Project# and 
ASSIGNED_TO.Emp# = EMPLOYEE.Emp# 


Compile the names of project where employee 107 is assigned. 


select Project_Name 

from ASSIGNED_TO, PROJECT 

where ASSIGNED_TO.Project# = PROJECT.Project# and 
EMPLOYEE.Emp# = 107 


Access all employees assigned to projects whose chief architect is 
employee 109. 


select a.Emp# 

from ASSIGNED_TO a, PROJECT p 

where a.Project# = p.Project# and 
p.Cheif_Architect = 109 


Derive the list of employees who are assigned to all projects where 
employee 109 is the chief architect. 


select al.Emp# 
from ASSIGNED TO al 
where (select a2.Project# 
from ASSIGNED TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select p.Project# 
from PROJECT p 
where p.Cheif_Architect = 109) 


or 


select al.Emp# 
from ASSIGNED TO al 
where not exists 
(select * 
from PROJECT p 
where p.Cheif_Architect = 109 and 
not exists 
(select * 
from ASSIGNED TO a2 
where al.Emp# = a2.Emp# and 
a2.Project# = p.Project# )) 


Get all project names to which employee 107 is not assigned. 


select Project_Name 
from PROJECT 
where Project# not in 
(select Project# 
from ASSIGNED _TO 
where Emp# = 107) 
or 


select Project_Name 
from PROJECT p 
where not exists 
(select * 
from ASSIGNED TO a 
where p.Project# = a.Project# and 
Emp# = 107) 


or 


(select p.Project_Name 

from PROJECT p 

where Project# in 
(select distinct p1.Project# 
from PROJECT p1) 
minus 
(select distinct a.Project# 
from ASSIGNED TO a 
where a.Emp# = 107)) 


Get complete details of employees who are assigned to projects not 
assigned to employee 107. 


select e.Emp# e.EmpName 
from EMPLOYEE e, PROJECT p 
where e.Project# = p.Project# 
and not exists 
(select * 
from ASSIGNED TO a 


where a.Project# = p.Project# and 
a.Emp# = 107) 


Sas 
SQL 


select a,b 
from REL1 
where b = 'B1' or b = 'B2' 


QUEL 


range of r is REL1 

retrieve (r.all) 

where r.b = 'B1' or r.b = 'B2' 
QBE 


REL1 A B 


P. Xx Bl 
Y B2 


5.6. 
SQL 


(a) List all modules that use the HEAPSORT and 
BINARY_SEARCH modules. 


select cl.Module 
from CONSISTS_OF cl, CONSISTS _OF c2 
where cl.Module = c2.Module and 
cl.Sub Module = 'HEAPSORT' and 
c2.Sub Module = 'BINARY SEARCH' 


(b) List employees that were involved in the development of all 
modules that use the HEAPSORT and BINARY_SEARCH modules. 


select distinct Employee 
from DEVELOPED_BY, CONSISTS_OF cl, CONSISTS_OF c2 


where cl.Module = c2.Module and 
cl.Sub Module = 'HEAPSORT' and 
c2.Sub Module = 'BINARY SEARCH' and 
cl.Module = DEVELOPED BY.Module 


QUEL 


(a) List all modules that use the HEAPSORT and 
BINARY_SEARCH modules. 


range of cl is CONSISTS_OF 

range of c2 is CONSISTS_OF 

retrieve (c1.Module) 

where cl.Module = c2.Module and 
cl.Sub_Module = 'HEAPSORT' and 
c2.Sub_ Module = 'BINARY SEARCH' 


(b) List employees that were involved in the development of all 
modules that use the HEAPSORT and BINARY SEARCH modules. 


range of cl is CONSISTS_OF 

range of c2 is CONSISTS_OF 

range of d is DEVELOPED_BY 

retrieve (d.Employee) 

where cl.Module = c2.Module and 
cl.Sub_Module = 'HEAPSORT' and 
c2.Sub Module = 'BINARY SEARCH' and 
cl.Module = d.Module 


The above query does not list employees who are involved 
indirectly with the development of HEAPSORT or BINARY_SEARCH. 
One level of indirection can be obtained as shown below and a 
modification can be used to get two level of indirection. A 
multilevel indirection is not expressible in relational algebra 
calculus and hence in SQL or QUEL. 


select distinct Employee 
from DEVELOPED _BY, CONSISTS_OF cl, CONSISTS_OF c2 
where cl.Sub Module = c2.Module and 

(c2.Sub_ Module = 'HEAPSORT' or 


c2.Sub Module = 'BINARY SEARCH’) and 
cl.Module = DEVELOPED BY.Module 


range of cl is CONSISTS_OF 

range of c2 is CONSISTS_OF 

range of d is DEVELOPED_BY 

retrieve (d.Employee) 

where cl1.Sub Module = c2.Module and 
(c2.Sub Module = 'HEAPSORT' or 
c2.Sub_ Module = 'BINARY SEARCH’) and 
cl.Module = d.Module 


5.8. 
SQL 


update Employee 
set Pay_Rate = 1.05 * Pay_Rate 
where Empl_No in 
(select Empl_No 
from DUTY_ALLOCATION 
where Posting No = 7 and 
Shift = 3) 


QUEL 


range of e is Employee 

range of d is DUTY_ALLOCATION 

replace e (Pay_Rate = 1.05 * Pay_Rate) 
where e.Empl_No = d.Empl_No and 
d.Posting No = 7 and 
d.Shift = 3 


5.10. 
(1) Get Emp# of employees working on project numbered COMP353. 


select Emp# 
from ASSIGNED TO 
where Project# = 'COMP353' 


(ii) Get details of employees(name and number) working on project 
COMP353. 


select EMPLOYEE.Emp#, EmpName 

from ASSIGNED_TO, EMPLOYEE 

where EMPLOYEE.Emp = ASSIGNED_TO.Emp and 
Project# = 'COMP353' 


(iii) Get details of employees working on all Database projects" 


The following gives employees working on at-least one Database 
project 


select EMPLOYEE.Emp#, EmpName 

from ASSIGNED_TO, EMPLOYEE, PROJECT 

where Project_Name = 'Database' and 
PROJECT.Project# = ASSIGNED_TO.Project# and 
EMPLOYEE.Emp = ASSIGNED_TO.Emp 


To get details for employees working on all Database projects we use 
the following query. 


select e.Emp#, e.EmpName 
from EMPLOYEE e 
where e.Emp# in 
(select al.Emp# 
from ASSIGNED _TO al 
where (select distinct a2.Project# 
from ASSIGNED _TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select p.Project# 
from PROJECT p 
where p.Project_Name = 'Database' 


or 


select e.Emp#, e.EmpName 
from EMPLOYEE e 
where e.Emp# in 
(select al.Emp# 
from ASSIGNED TO al 
where not exists 
(select p.Project# 
from PROJECT p 
where p.Project_Name = 'Database' and 
not exists 
(select * 
from ASSIGNED TO a2 
where a2.Project# = p.Project# and 
al.Emp# = a2.Emp#))) 


(iv) Get details of employees working on both COMP353 and 
COMP354. 


select Emp#, EmpName 
from EMPLOYEE 
where Emp# in 
(select al.Emp# 
from ASSIGNED_TO al 
where (select distinct a2.Project# 
from ASSIGNED _TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select distinct a3.Project# 
from ASSIGNED_TO a3 
where a3.Project# = 'COMP353' or 
a3.Project# = 'COMP354')) 


(v) Get employee number of employees who work on at least all 
those projects that employee 107 works on. 


select al.Emp# 

from ASSIGNED TO al 

where (select distinct a2.Project# 
from ASSIGNED TO a2 


where al.Emp# = a2.Emp#) 
contains 
(select distinct a3.Project# 
from ASSIGNED TO a3 
where a3.Emp# = 107) 
or 


select al.Emp# 
from ASSIGNED TO al 
where not exists 
(select * 
from ASSIGNED TO a2 
where a2.Emp# = 107 and not exists 
(select * 
from ASSIGNED TO a3 
where a3.Emp# = al.Emp# and 
a3.Project# = al.Project# )) 


(vi) Get employee number of employees who do not work on project 
COMP453. 


select distinct Emp# 

from ASSIGNED TO al 

minus 

(select distinct Emp# 

from ASSIGNED TO 

where Project# = al.'COMP453') 


or 
select al.Emp# 
from ASSIGNED TO al 
where not exists 
(select * 
from ASSIGNED TO a2 
where a2.Project# = 'COMP453'and 
a2.Emp# = al.Emp#) 


(vii) Get employee number of employees who work on all projects. 


select al.Emp# 
from ASSIGNED TO al 


where (select distinct a2.Project# 
from ASSIGNED_TO a2 
where al.Emp# = a2.Emp#) 
contains 
(select p.Project# 
from PROJECT p) 


or 


select al.Emp# 
from ASSIGNED TO al 
where not exists 
(select * 
from PROJECT p 
where not exists 
(select * 
from ASSIGNED TO a2 
where a2.Project# = p.Project# and 
al.Emp# = a2.Emp#)) 


(viii) Get employee number of employees who work on at least one 
project that employee 107 works on. 


select al.Emp# 

from ASSIGNED TO al 

where Emp# = 107 and 

Project# in 
(select distinct a2.Project# 
from ASSIGNED TO a2 
where a2.Emp# = 107) 


Sek hy 


(1) Get Emp# of employees working on project number COMP353. 


range of a is ASSIGNED_TO 
retrieve (a.Emp#) 
where a.Project# = 'COMP353' 


(ii) Get details of employees(name and number) working on project 
COMP353. 


range of e is EMPLOYEE 

range of a is ASSIGNED_TO 

retrieve (e.Emp#, e.EmpName) 

where e.Emp = a.Emp and 
a.Project# = 'COMP353' 


(iii) Get details of employees working on all Database projects. 


The following query finds employees who are working on any one 
Database project: 


range of a is ASSIGNED_TO 

range of e is EMPLOYEE 

range of p is PROJECT 

retrieve (e.Emp#, e.EmpName) 

where p.Project_Name = 'Database' and 
p.Project# = a.Project# and 
e.Emp# = a.Emp# 


To find employees who are working on all Database projects, we use 
the following: 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of p is PROJECT 
retrieve (al.Emp#) 
where any (p.Project# by al.Emp# 
where p.Project_Name = 'Database' and 
any (a2.Project# by al.Emp#, p.Project# 
where al.Emp# = a2.Emp# and 
a2.Project# = p.Project#) = 0) = 
0 


(iv) Get details of employees working on both COMP353 and 
COMP354. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of a3 is ASSIGNED_TO 
range of e is EMPLOYEE 
retrieve (e.Emp#, e.EmpName) 


where e.Emp# = al.Emp# and 
any (a2.Project# by al.Emp# 
where (a2.Project# = COMP353 or 
a2.Project# = COMP354) and 
any (a3.Project# by al.Emp#, a2.Project# 
where al.Emp# = a3.Emp# and 
a2.Project# = a3.Project#) =0) =0) 


(v) Get employee number of employees who work on at least all 
those projects that employee 107 works on. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of a3 is ASSIGNED_TO 
retrieve (al.Emp#) 
where al.Emp# ~ 107 and 
any (a2.Project# by al.Emp# 
where a2.Emp# = 107 and 
any (a3.Project# by al.Emp#, a2.Project# 
where a3.Project# and 
al.Emp# = a3.Emp#) = 0) = 0 


(vi) Get employee number of employees who do not work on project 
COMP453. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
retrieve (al.Emp#) 
where any (a2.Emp# by al.Emp# 
where al.Emp# = a2.Emp# and 
a2.Project# = COMP453) = 0 


(vii) Get employee number of employees who work on all projects. 


range of al is ASSIGNED_TO 
range of a2 is ASSIGNED_TO 
range of p is PROJECT 
retrieve (al.Emp#) 
where any (p.Project# by al.Emp# 
where any (a2.Project# by al.Emp#, p.Project# 


where al.Emp# = a2.Emp# and 
a2.Project# = p.Project#) = 0) = 0 


(viii) Get employee number of employees who work on at least one 
project that employee 107 works on. 


range of al is ASSIGNED_TO 

range of a2 is ASSIGNED_TO 

retrieve (al.Emp#) 

where al.Emp# “107 and 
a2.Project# = al.Project# and 
a2.Emp# = 107 


5.14. Using SQL, get the Empl_No, Skill, and average chef's pay rate 
for the EMPLOYEE relation shown in Figure 5.6. 


Consider the temporary relation TEMP1(Empl_No, Skill) as follows: 


insert into TEMP1 
select Empl_No, Skill 
from EMPLOYEE 


Consider the temporary relation TEMP2(Pay_Rate) as follows: 


insert into TEMP2 
select avg(Pay_Rate) 
from EMPLOYEE 
where Skill = 'chef 


Now the required response can be derived as: 
select * 


from TEMP1, TEMP2 


5.17 
(i) Give the names of the players who played as forwards in 1987 
with the franchise "Blades". 


(a) SQL 


select f.name 

from FORWARD f 

where f.franchise_name = 'Blades' and 
f.year = 1987 


(b) QUEL 


range of f is FORWARD 

retrieve (f.name) 

where f.franchise_name = 'Blades' and 
f.year = 1987 


(ii) Find the names of all the goalies who played with the forward 
Ozzy Xavier over the span of his hockey career. 


(a) SQL 


select g.name 
from FORWARD f, GOAL g 
where f.name = 'Ozzy Xavier' and 
f.year = g.year and 
f.franchise_name = g.franchise_name 


(b) QUEL 


range of f is FORWARD 

range of g is GOAL 

retrieve (g.name) 

where f.name = 'Ozzy Xavier' and 
f.year = g.year and 
f.franchisename = g.franchise_name 


(iii) List forwards and the franchises for those forwards who had at 
least 50 goals in both of the years 1985 and 1986. A player must 
have at least 50 goals in both the years, however may be with two 
different franchises. 


(a) SQL 


select f.name, f.franchise_name, f1.franchise_name 
from FORWARD f, FORWARD f1 
where f.name = fl.name and 

f_year = 1985 and 

fl.year = 1986 and 

f.goals > = 50 and 

fl.goals > = 50 


(b) QUEL 


range of f is FORWARD 
range of f1 is FORWARD 
retrieve (f.name, f.franchise_name, f1.franchise_name) 
where f.name = fl.name and 
fyear = 1985 and 
fl.year = 1986 and 
f.goals > = 50 and 
fl.goals > = 50 


(iv) Give the complete details of players who played for the same 
franchises that Ozzy Xavier did over his career. However, they may 
not necessarily have played in the same year or as forwards. 


(a) SQL 


select * 
from PLAYER p 
where p.name in 
((select f1.name 
from FORWARD f1 
where fl.name =~ 'Ozzy Xavier' and 
not exists 
(select * 
from FORWARD f2 
where f2.name = 'Ozzy Xavier' and not exists 
(select * 


from FORWARD f3 

where f3.name = fl.name and 

£3. franchise_name = 
f1.franchise_name ))) 


union 
(select g.name 
from GOAL g 
where not exists 
(select * 
from FORWARD f2 
where f2.name = 'Ozzy Xavier' and not exists 
(select * 
from GOAL g1 
where g.name = g1.name and 
g.franchise_name = g1.franchise_name )))) 
(b) QUEL 


range of f1 is FORWARD 
range of f2 is FORWARD 
range of f3 is FORWARD 
retrieve into TEMP(f1.name) 
where fl.name =~ 'Ozzy Xavier' and 

any (f2.franchise_name by f1.name 

where f2.name = 'Ozzy Xavier' and 

any (f3.franchise_name by f1.name, f2.franchise_name 

where f2.franchise_name = f3.franchise_name 
and 
fl.name = 
f3.name) =0) =0 
range of g1 is GOAL 
range of f2 is FORWARD 
range of g3 is GOAL 
retrieve into TEMP(g1.name) 
where any (f2.franchise_name by g1.name 
where f2.name = 'Ozzy Xavier' and 
any (g3.franchise_name by g1.name, f2.franchise_name 
where f2.franchise_name = g3.franchise_name 
and 
gl.name = 


g3.name ) = 0) = 0 
range of t is TEMP 
range of p is PLAYER 
retrieve (p.all) 

where p.name = t.name 


(v) Compile the list of goalies who played, during their career, for 
franchises in St. Louis, Edmonton and Paris. A goalie should be 
listed if and only if he had played in all three cities. 


(a) SQL 


select g1.name 

from GOAL g1, GOAL g2, GOAL g3, TEAM t1, TEAM t2 , TEAM t3 
where gl.name = g2.name and g1.name = g3.name and 
gl.franchise_name = t1.franchise_name and 
g2.franchise_name = t2.franchise_name and 
g3.franchise_name = t3.franchise_name and 

tl.city = 'St. Louis' and 

t2.city = 'Edmonton' and 

t3.city = 'Paris' and 

gl.year = tl.year and 

g2.year = t2.year and 

g3.year = t3.year 


(b) QUEL 


range of g1 is GOAL 

range of g2 is GOAL 

range of g3 is GOAL 

range of tl is TEAM 

range of t2 is TEAM 

range of t3 is TEAM 

retrieve (g1.name) 

where gl.name = g2.name and g1.name = g3.name and 
gl.franchise_name = t1.franchise_name and 
g2.franchise_name = t2.franchise_name and 
g3.franchise_name = t3.franchise_name and 
tl.city = 'St. Louis' and 

t2.city = 'Edmonton' and 


t3.city = 'Paris' and 
gl.year = tl.year and 
g2.year = t2.year and 
g3.year = t3.year 


6. Relational Database Design 


Objectives: This chapter introduces the student to the following 
concepts: 

Relation scheme 

Anomalies in database as a result of bad design and normal forms 
Concept of decomposition of a relation scheme 

Concept of universal relation 

Functional dependency and logical implication 

Inference axioms 

Concept of closures: of a set of FDs, of a set of attributes under a set 
of FDs 

Membership of a FD in the closure of a set of FDs 

Non-redundant and minimum covers 

Concept of Full Functional, Partial and Transitive dependencies 
Aim of relational database design: content and dependency 
preservation 

Concept of un-normalized relation and the first, second, third 
normal forms 

Concept of lossless and lossy decomposition 

Concept of dependency-preserving decomposition 

Algorithm to verify if a decomposition is: lossless, dependency- 
preserving 

Algorithm for deriving a lossless and dependency-preserving third 
normal form relation database 

Concept of the Boyce Codd normal form 

Algorithm for decomposing into a lossless-join Boyce Codd normal 
form 


Solution to Selected Exercises: 


6.1. 


The FDs in the set F are already left-reduced. In the set of FDs 
F={A — B, BC — D, D — BC, DE — ©}, the DE — © is redundant 
since its RHS is ©. However, if the FD is included to indicate that 
there is some form of non-functional dependency, we may leave it 
in. Another reason to leave-in this FD is to include the attribute E 
which does not appear in any other FD in the set F. Writing the 
remaining FDs in the simple form we get: 


F'={A — B, BC — D, D > B, D> CG}. 


None of these FDs are redundant hence this set forms a canonical 
cover. 


F.={A — B, BC ~— D, D = B, D > C}. 


Using F- we get the following decompositions 


R1 = (£) 
R2 = (AB) 
R3 = (BCD) 
R4 = (BD) 
R5 = (CD) 


Since ADE is a key of R, we modify R1 to (ADE) and in this way 
keep the attributes DE together. R4 and R5 may be combined into a 
single relation scheme (BCD) which already exists as R3! 

6.2. 


Given: R{ABCDE} F={AB — CD, ABC > E, C>A} 
ABC+ = ABCDE 


Candidate keys: AB, BC 
The relation is in the 1NF since there is a partial dependency in F. 


6.3. 


Given R{ABCDEF} F={ABC — DE, AB — D, DE — ABCF, 
Ee Ct 


R is in 1NF. The key of this relation are: ABC and DE. However, the 
FDs AB — D, E — C are partial dependencies and hence R is not in 
3NF. 


A lossless and dependency preserving decomposition of R is: 
R1{ABCE}, R2{ABD}, R3{ADE}, R4{BDE}, R5{DEF}, R6{CE}. 
6.4. 


R{T, C, Y, G, D, V} FD's{T > C, TY 
— G, TY — D, CG > V} 


The decomposition of R into R1{TCD} and R2{TGDVY} is lossless 
but not dependency preserving. It is lossless since, the common 
attributes TD forms a superkey of the first relation. It is not 
dependency preserving since the FD CG — V is not preserved in the 
decomposition. 


The decomposition of R into R1{TC}, R2{TGDY} and R3{CGV} isa 
lossless and dependency preserving 3NF decomposition. This 
decomposition is also in BCNF since each FDs in each relation 
involve only the superkeys of the decomposed relation. 


6.7. 

Left-reduced 
Right-reduced Non-redundant covers 
ABCD A> BCD A 
D A>D A> BCD 
CDE DE D> 
E E>D E>CD 
ECD E>CD jee 
D D~>ABCEH D> AEH 
D> AH D> AH D> 


AH 


ABH > BD 
Y 

DH > BC 
BC 


6.8. 
R{ABCDEFGH} 


R{CEH} R{ABCDEFG 


R{ABCDEG} 


AH > BD 


D>BC 


R{BCEF} 


R{ABCDE} 


R{BCEG} 
R{ABDE} 


R{AC} 


R{ABD} 


R{AE} 


R{AB} R{AD} 


This decomposition is not dependency preserving since among others 


the FD BCD > E is not preserved. 


AH > 


6.9. 
Given FD set Left-reduced 
Right-reduced Canonical cover 
I->kK I>kK 
I-kK I + BCDEFGJK 
Al — BFG I — BFG I= 
BFG K—AH 
IC — ADE I — ADE I= 
DE 
BIG > CJ I>C 
I>~G 
K— AH K + AH K-> 


AH 


The decomposition of R into R1 < {BCDEFGIJK}, {I - BCDEFGJK } 
>, and R2< {AHK}, {K — AH}> is both lossless and dependency 
preserving. Furthermore, this decomposition is also in BCNF. 


6.10. 

Given set Left-reduced 

Right-reduced Canonical cover 

A — BCDE A — BCDE A> 
Cc A->C 

B— ACDE B — ACDE B= 
Cc B>C 

C — ABDE C — ABDE C= 
ABDE C — ABDE 


The decomposition of R into R1{AC}, R2{BC}, R3{CDE} is lossless. 
To preserve dependeny we may decomose R into R1{AC}, R2{BC}, 
R3{ABCDE}. However, this requires some duplication. 


6.13. 
BCD+ = ABCDEF. 


6.17. 


Under the modified assumption TEACHES is not in 2NF, since 
Room_Cap, a non-prime attribute is not dependent on the key of the 
relation. Its decomposition into COURSE_DETAILS and 
ROOML_DETAILS is a 3NF decomposition which is both lossless and 
dependency preserving. 


6.18. 


The decomposition is lossy since the final version of the 
TABLE_LOSSY shown below, does not have any row with all a's. 


A B Cc D E 


R1 du Os Ac Op Biz 
R2 oa Os Ac Op {Son 
R3 sa (3B Ac Qp Qe 


6.22. 


With only two atomic attributes, we can say that the relation is in 
BCNF form and, therefore in 3NF form. 


6.23. 


Since A is a candidate key, we can deduce that the FD A > BCD is 
satisfied. This means that the relation is at least in the 2NF. However, 
it may have a transitive dependency such as B > C and hence may 
not be in any higher normal form. 


7. Synthesis Approach and 
Higher Order Normal Form 


Objectives: This is an optional chapter for a first course in database 
systems. The chapter introduces the student to the synthesis 
approach to 3NF relational database design. We then turn our 
attention to the higher order normal forms. The concept of multi- 
valued dependency and axioms which involve both functional and 
multi-valued dependencies are examined. The fourth normal form 
and a lossless decomposition algorithm for it is given. The concept 
of join dependency and a normal form for it is introduced. Finally, 
we introduce a scheme whereby all general constraints could be 
enforced via domain and key constraint, and the associated normal 
form, known as domain key normal form. 


Solution to selected exercises 
7A. 
R1 = {AB}, R2 = {BCD}, R3 = {DE}, R4= {ADE} 
7 
*TACE, BD, CE], *[ABC, BCD, CDE], *[AB, BC, CD, ADE] 
R1 = {ABC}, R2 = {BCD}, R3 = {CDE} 
TA. 
(A) (E) (F) 


8. The Network Model 


Objectives: This chapter as well as the next have a slightly different 
style than the rest of the text. This has been done to allow these 
chapters to be studied either with very little help from the instructor 
or their coverage could be entrusted to a tutor or a T.A. It is expected 
that the instructor has covered the basic concept of these models in 
Chapter 2. The chapters at hand use the same database example. 

The chapter introduces the student to the following concepts of the 
network data model: 


The use of the DBTG set to express a one-to-many relationship 
The restriction of the DBTG set construct 

Implementation of the DBTG set 

Expressing a many-to-many relationship in the network model 


Data definition facility in the network model and different types of 
set memberships 


Data manipulation facility 


Concept of currency indicators, status registers, record templates and 
navigating through the network database. 


Solution to selected Exercises 


8.4 


Schema name is SCHOOL 


type STUDENT = record 
Student_No: string; 
Name: string; 

Address: string; 

end 


type COURSE = record 
Course_No: string; 
Course_Name: string; 
end; 


type ENROLLMENT = record 
Course_No: string; 
Student_No: string; 

end; 


setis ENROLLED_IN 

owner is STUDENT 

member is ENROLLMENT optional manual 
end 


set is class_list 

owner is COURSE 

member is ENROLLMENT manual optional 
end 


class list 


8.7 


CAN SUPPLY SOURCE 


Schema name is SUPPLIER_PARTS-PROJECTS 


type SUPPLIER = record 
Supplier#: string; 
Company-Name: string; 
end 


type LOCAL = record 
City: string; 
end 


type PARTS = record 
Part#: string; 

Weight: integer; 

end; 


type PROJECTS = record 
Project#: string; 
end; 


type QUANTITY = record 
Project#: string; 

Part#: string; 

Quant: integer; 

end; 


type SUPPLY_PARTS = record 
Supplier#: string; 

Part#: string; 

end; 


type ORDER = record 
Supplier#: string; 

Part#: string; 
Date_of_Delivery: string; 
end; 


set is LOCATEDIN 

owner is SUPPLIER 

member is LOCAL automatic fixed 
end 


setis WHERE USED 

owner is PARTS 

member is QUANTITY automatic fixed 
end 


setis USES 

owner is PROJECTS 

member is QUANTITY automatic fixed 
end 


set is CAN SUPPLY 


owner is SUPPLIER 
member is SUPPLY_PARTS automatic fixed 
end 


set is SOURCE 

owner is PARTS 

member is SUPPLY_PARTS automatic fixed 
end 


set is SUPPLYING 

owner is SUPPLIER 

member is ORDER automatic fixed 
end 


setis ORDERED 

owner is PARTS 

member is ORDER automatic fixed 
end 

8.7 1. 


SUPPLIER. Supplier# := supplier; 
find any SUPPLIER using SUPPLIER. Supplier#; 
find first SUPPLY_PARTS within CAN_SUPPLY; 
while DB_Status = 0 do 

begin 

get SUPPLY_PARTS; 

display ('Supplier', supplier: ‘supplies part ', 
SUPPLY_PARTS. Part# ) 

find next SUPPLY_PARTS within CAN_SUPPLY; 
end 


8.7 iL. 


SUPPLIER. Supplier# := supplier; 

find any SUPPLIER using SUPPLIER. Supplier#; 

if DB_Status = 0 then get SUPPLIER 

if DB_Status = 0 then find first LOCAL within LOCATEDIN; 


while DB_Status = 0 do 

begin 

get LOCAL; 

display (' Supplier's ', SUPPLIER. Supplier#, 
‘city is', LOCAL. City); 

find next LOCAL within LOCATEDIN; 

end; 


8.7 ill. 


We assume that there is an array parts_list as given below where we 
will first store the list of all parts supplied by supplier:. 


parts_list = array [1..max_no_parts] of string; 
n:=1; 

SUPPLIER. Supplier# := supplier; 

find any SUPPLIER using SUPPLIER. Supplier#; 
find first SUPPLY_PARTS within CAN_SUPPLY; 
while DB_Status = 0 do 

begin 

get SUPPLY_PARTS; 

parts_list[n] -= SUPPLY_PARTS. Part# 
n:i=n+1; 

find next SUPPLY_PARTS within CAN_SUPPLY; 
end 


Now we use the set SOURCE to find at least another supplier who 
supplies each of these parts as follows: 


fori:=1tondo 
begin; 
PARTS.Part# := parts_list[i]; 
find any PARTS using PARTS.Part#; 
find first SUPPLY_PARTS within SOURCE; 
found := false; 
while DB_Status = 0 and not found do 
begin 


get SUPPLY_PARTS; 

if SUPPLY_PARTS.Supplier# <> supplier: then 
found := true; 

else find next SUPPLY_PARTS within SOURCE; 
end 

if found then 

display (' Another supplier for part ' PARTS.Part#, 
‘is', SUPPLY_PARTS.Supplier#) 

else display (' No other supplier supplies the part ', 
PARTS. Part#); 

end; 


8.7 iv. 


We assume that there is an array parts_list where we will first store 
the list of all parts supplied by supplier: (as in the previous example). 
Now for each such part, we find the set of projects where it is used. 
The union of all these sets gives the projects where supplier: may 
supply. These projects are created in the array projects_list as shown 
below: 


projects_list = array[1..max_no_of_projects] of string; 
m :=0; 
fori:=1tondo 

begin 

PARTS.Part# = parts_list[i]; 

find any PARTS using PARTS.Part#; 

find first QUANTITY within WHERE_USED; 

while DB_Status = 0 do 


begin 

get QUANTITY; 
found := false; 
jal 


while not found and j < m do 
if projects_list[j] = QUANTITY .Project# then 
found := true 


else j:=jt+l; 

if not found then 

begin 

m:=m+1; 

projects_list{m] := QUANTITY .Project#; 

end; 

find next QUANTITY within WHERE_USED 
end { while } 

end {for i } 


8.7 v. 


PARTS. Part# := parti; 

find any PARTS using PARTS.Part#; 

find first SUPPLY_PARTS within SOURCE; 

while DB_Status = 0 do 

begin 

get SUPPLY_PARTS; 

display (' Supplier is ', SUPPLY_PARTS. Supplier#) 
find next SUPPLY_PARTS within CAN_SUPPLY; 
end 


8.7 Vi. 


PARTS. Part# := parti; 

find any PARTS using PARTS.Part#; 

find first QUANTITY within WHERE_USED; 
while DB_Status =0 do 

begin 

get QUANTITY; 

display (' Project is ', QUANTITY. Project#) 
find next QUANTITY within WHERE_USED; 
end 


8.8 1. True 


8.8 iL. 


8.8 ill. 


8.8 iv. 


8.8 v. 


8.8 Vi. 


8.8 Vil. 


False 


False 


True 


False 


True 


True 


9. The Hierarchical Data 
Model 


Objectives: As mentioned before, this and the previous chapter have 
a slightly different style than the rest of the text. This is to allow 
these chapters to be studied either with very little help from the 
instructor or their coverage be entrusted to a tutor or a T.A. 

The chapter introduces the student to the following concepts of the 
hierarchical data model: 

Concept of ordered tree 

Representation of data and relationship using the ordered tree 
Representation of a many-to-many relationship in the hierarchical 
model 

Data definition facilities 

Data manipulation in the hierarchical model 

Concept of currency indicators, status registers, record templates and 
navigating through the hierarchical database 


Solution to selected exercises 


9.3 


BOOK L!<L L/----- >L) CLIENT 


RESERVED _BY1J--L! |J---L/BOOK_RESERVED 


The paired bi-directional logical relationship, with its 
associated symmetrical virtual records, is used in the hierarchical 
model to implement a many-to-many relationship. The many-to- 
many relationship between clients and the books they reserve may be 
implemented as shown above: 


type BOOK = record 
Author: string; 

Title: string; 
Call_No: string; 

end 


type CLIENT = record 
Client_No: integer; 
Name: string; 
Address: string; 

end 


type RESERVED_BY = record 

{ Client_No: integer; 

Name: string; 

Address: string; } 

(* virtual of logical parent 

CLIENT in CLIENT_BOOK_TREE; *) 
end 


type BOOK_RESERVED = record 

{ Author: string; 

Title: string; 

Call_No: string; } 

(* virtual of logical parent 

BOOK in BOOK_CLIENT_TREE; *) 
end 


tree is CLIENT_BOOK_TREE 
CLIENT is parent 
BOOK_RESERVED is child 


end 


tree is BOOK_CLIENT_TREE 


BOOK is parent 
RESERVED_BY is child 


end 


9.6 


Since the child records are linked directly to the parent record by 
hierarchical pointers, there is no need for foreign keys. 


oT 


LAB WARD DOCTOR PATIENT 


tree is HOSPITAL_TREE 
HOSPITAL is parent 
LAB is child 

WARD is child 
DOCTOR is child 


PATIENT is child 
end 


tree is WARD_TREE 
WARD is parent 
W_DOCTOR is child 
W_PATIENT is child 
end 


tree is DOCTOR_TREE 
DOCTOR is parent 
D_WARD is child 
SPECIALITY is child 
D_PATIENT is child 
end 


tree is PATIENT_TREE 
PATIENT is parent 
P_DOCTOR is child 
end 


type HOSPITAL = record 
Hospital_Name: string; 
Address: string; 
Phone_No: string; 

end 


type LAB = record 
Lab_Name: string; 
Room_No: integer; 
Phone_No: string; 
end 


type WARD = record 
Ward_Name: string; 
Capacity: integer; 
end 


type DOCTOR = record 
D_Name: string; 
Current_Status: string; 
end 


type PATIENT = record 
P_Name: string; 
Address: string; 

Phone: string; 

end 


type W_DOCTOR = record 
{D_Name: string;} 

(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


type W_PATIENT = record 
{P_Name: string; } 

(* virtual of logical parent 
PATIENT in PATIENT_TREE *) 
end 


type D_WARD = record 

{ Ward_Name: string; } 

(* virtual of logical parent 
WARD in WARD_TREE *) 
end 


type SPECIALITY = record 
Speciality_Name : string; 
end 


type D_PATIENT = record 
{P_Name: string; } 
(* virtual of logical parent 


PATIENT in PATIENT_TREE *) 
end 


type P_DOCTOR = record 
{D_Name: string;} 

(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


9.8 a) 


get first HOSPITAL; 

while DB-Status = 0 do 

begin 

get next within parent LAB where Lab_Name = ‘haematology’; 
if DB-Status = 0 then display (HOSPITAL.Hospital_Name); 
get next HOSPITAL; 

end 


9.8 b) 


get first HOSPITAL; 
while DB-Status = 0 do 
begin 
get next within parent WARD where WARD.Capacity > 4; 
while DB-Status = 0 do 
begin 
display (HOSPITAL.Hospital_Name, WARD.Ward_Name ); 
get next within parent WARD where WARD.Capacity > 


4; 
end 
get next HOSPITAL 
end 


9.8 c) 


get first PATIENT where PATIENT.P_Name =' given '; 
if DB-Status = 0 

then get next within parent P_DOCTOR; 

while DB-Status = 0 do 

begin 

display (PATIENT.P_Name, P_DOCTOR.D_Name); 

get next within parent P_DOCTOR; 

end; 


9.8 d) 


get first DOCTOR; 

while DB-Status = 0 do 

begin 

get next within parent SPECIALITY where Speciality_Name = 


‘pediatrics’; 

if DB-Status = 0 

then display (DOCTOR.D_Name); 
get next DOCTOR; 

end 


9.8 e) 


no_of_doctors := 0; 

get first PATIENT where PATIENT.P_Name =' given '; 
if DB-Status = 0 

then get next within parent P_DOCTOR; 

while DB-Status = 0 do 

begin 

no_of_doctors := no_of_doctors + 1; 

display (PATIENT.P_Name, P_DOCTOR.D_Name); 
get next within parent P_DOCTOR; 

end; 

display (PATIENT.P_Name, 'Number of Doctors =', 
no_of_doctors); 


9.8 f) 


DOCTOR.D_Name := ' given '; 
DOCTOR. Current_Status' given '; 
insert (DOCTOR) where (HOSPITAL. Hospital_Name =' given '); 
for 1:= 1 to no_of _speciality do 
begin 
get (speciality); 
SPECIALITY .Speciality_Name := speciality; 
insert (SPECIALITY) where (DOCTOR.D_Name =' given '); 


end 
9.3 
BOOK [|/<L! L/----- >L!} CLIENT 
os 
Hl | | 
RESERVED BYL_-- ---LIBOOK_RESERVED 


The paired bi-directional logical relationship, with its 
associated symmetrical virtual records, is used in the hierarchical 
model to implement a many-to-many relationship. The many-to- 
many relationship between clients and the books they reserve may be 
implemented as shown above: 


type BOOK = record 
Author: string; 

Title: string; 
Call_No: string; 

end 


type CLIENT = record 
Client_No: integer; 
Name: string; 
Address: string; 


end 


type RESERVED_BY = record 

{ Client_No: integer; 

Name: string; 

Address: string; } 

(* virtual of logical parent 

CLIENT in CLIENT_BOOK_TREE; *) 
end 


type BOOK_RESERVED = record 
{ Author: string; 

Title: string; 

Call_No: string;} 

(* virtual of logical parent 

BOOK in BOOK_CLIENT_TREE; *) 
end 

tree is CLIENT_BOOK_TREE 
CLIENT is parent 
BOOK_RESERVED is child 

end 


tree is BOOK_CLIENT_TREE 
BOOK is parent 
RESERVED_BY is child 

end 


9.6 


Since the child records are linked directly to the parent record by 
hierarchical pointers, there is no need for foreign keys. 


oo 


LAB WARD DOCTOR PATIENT 


tree is HOSPITAL_TREE 
HOSPITAL is parent 
LAB is child 

WARD is child 
DOCTOR is child 
PATIENT is child 

end 


tree is WARD_TREE 
WARD is parent 
W_DOCTOR is child 
W_PATIENT is child 
end 


tree is DOCTOR_TREE 
DOCTOR is parent 
D_WARD is child 
SPECIALITY is child 
D_PATIENT is child 
end 


tree is PATIENT_TREE 
PATIENT is parent 
P_DOCTOR is child 
end 


type HOSPITAL = record 
Hospital_Name: string; 


Address: string; 
Phone_No: string; 
end 


type LAB = record 
Lab_Name: string; 
Room_No: integer; 
Phone_No: string; 
end 


type WARD = record 
Ward_Name: string; 
Capacity: integer; 
end 


type DOCTOR = record 
D_Name: string; 
Current_Status: string; 
end 


type PATIENT = record 
P_Name: string; 
Address: string; 

Phone: string; 

end 


type W_DOCTOR = record 
{D_Name: string;} 

(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


type W_PATIENT = record 
{P_Name: string; } 

(* virtual of logical parent 
PATIENT in PATIENT_TREE *) 
end 


type D_WARD = record 

{ Ward_Name: string; } 

(* virtual of logical parent 
WARD in WARD_TREE *) 
end 


type SPECIALITY = record 
Speciality_Name : string; 
end 


type D_PATIENT = record 
{P_Name: string; } 

(* virtual of logical parent 
PATIENT in PATIENT_TREE *) 
end 


type P_DOCTOR = record 
{D_Name: string; } 

(* virtual of logical parent 
DOCTOR in DOCTOR_TREE *) 
end 


9.8 a) 


get first HOSPITAL; 
while DB-Status = 0 do 

begin 

get next within parent LAB where Lab_Name = ‘haematology’; 
if DB-Status = 0 then display (HOSPITAL.Hospital_Name); 
get next HOSPITAL; 

end 


9.8 b) 


get first HOSPITAL; 
while DB-Status = 0 do 


begin 

get next within parent WARD where WARD.Capacity > 4; 

while DB-Status = 0 do 

begin 

display (HOSPITAL.Hospital_Name, WARD.Ward_Name ); 

get next within parent WARD where WARD.Capacity > 
4; 

end 

get next HOSPITAL 

end 

9.8 c) 


get first PATIENT where PATIENT.P_Name =' given '; 
if DB-Status = 0 

then get next within parent P_DOCTOR; 

while DB-Status = 0 do 

begin 

display (PATIENT.P_Name, P_LDOCTOR.D_Name); 

get next within parent P_DOCTOR; 

end; 


9.8 d) 


get first DOCTOR; 

while DB-Status = 0 do 

begin 

get next within parent SPECIALITY where Speciality_Name = 


‘pediatrics’; 

if DB-Status = 0 

then display (DOCTOR.D_Name); 
get next DOCTOR; 

end 


9.8 e) 


no_of_doctors := 0; 


get first PATIENT where PATIENT.P_Name =' given '; 
if DB-Status = 0 

then get next within parent P_DOCTOR; 

while DB-Status = 0 do 

begin 

no_of_doctors := no_of_doctors + 1; 

display (PATIENT.P_Name, P_DOCTOR.D_Name); 
get next within parent P_DOCTOR; 

end; 

display (PATIENT.P_Name, 'Number of Doctors =', 
no_of_doctors); 


9.8 f) 


DOCTOR.D_Name := ' given '; 
DOCTOR. Current_Status' given '; 
insert (DOCTOR) where (HOSPITAL. Hospital_Name =' given '); 
for 1:= 1 to no_of _speciality do 
begin 
get (speciality); 
SPECIALITY .Speciality_Name := speciality; 
insert (SPECIALITY) where (DOCTOR.D_Name =' given '); 
end 


10. Query Processing 


Objectives: This chapter introduces the student to the following 
concepts: 


In this chapter we focus on different aspects of converting a user's 
query into a standard form and thence into a plan to be executed 
against the database to generate a response. 


Solution to selected exercises 


10.2. 

(a) Let X = rarts.P#(Oparts.Name=bor(PARTS)) and 

YY = JUSuppLy.s#,SUPPLY.Price)X 

The required response is given as: Y | SUPPLIER 
The query tree is given as: 


required response 


x 


SUPPLIER st(suppLy.s#,SUPPLY.Price) 


x 


JUPARTS.N# 


SUPPLY 


OPARTS.Name = bolt 


PARTS 
(b) Let 
X = Ieparts.P#(OPARts.Name=boi( PARTS)), 


Y = Itsuppry.s#(X x JUSUPPLY.P#,SUPPLY.s#( OSUPPLY.Price<.01(SUPPLY ))) 
Z=Y™ (Tts#,P#( OCAN_SUPPLY.Quality>xX CAN_SUPPLY )) 
The required response is obtained as: Z | PARTS 


required response 


Xl 


x 


JUS#,P# JUSUPPLY.S# 


OCAN_SUPPLY. Quality > x | 
JUPARTS.P# JUSUPPLY.P#,SUPPLY.S# 
CAN_SUPPLY 


OPARTS.Name= bolt OSUPPLY.Price<.01 


PARTS SUPPLY 


10.3. Repeat exercise 4 from Chapter 4, presenting both an efficient 
relational algebraic expression and the corresponding query tree. 


(a) 
TIssENROLLM (O(rEACH.Prof='Smith' VTEACH.Prof='Jones’) L EACH) 


required response 
IUs# 


x 
ENROLL O(TEACH.Prof='Smith'V TEACH.Prof='Jones') 


TEACH 
(b) 


IIss«“ENROLL DX (0 sz,c4section( TEACH 1 ADVISE))) 


required response 
Tis# 


OS#,C#, Section 


ENROLL Xx 


TEACH ADVISE 


(c) 
Let TEACH] and TEACH2 be copies of the relation TEACH. 
Let R = TEACH] x TEACH2, then 


S =O(TEACHI .Prof#=TEACH2. Prof#\ TEACH 1. C#H=TEACH2. C#A TEACH. Section! TEACH2. Section (R) 


The required response is given by [TreacuiproaS 


required response 
JUTEACH1.Prof# 


XxX TEACH1.Prof# = TEACH2. Prof# A TEACH1.C# = TEACH2. C#ATEACH1.Section|_ TEACH2. Section 


TEACH1 TEACH2 
(d) 


PASS(C#)= Itc#(Ocraves.Gradel 1? GRA DESMO stup ent. sname='John Doe’) 
STUDENT)) 

HAS_PRE_REQ(C#, Pre_C#)=(Oreacu.cf TEACH) x PASS[Pre_C#] 
CANNOTDO(C#) = stc( PRE_REQ - HAS_PRE_REQ) 
CANDO(C#) = (stc¥K TEACH) - CANNOTDO 

CAN_ENROLL(C#) = CANDO(C#) - PASS(C#). 


required response 


CAN_ENROLL 


CANNOTDO 


PRE REQ HAS PRE REQ 


JUPre_C# 


_] PASS 
OTEACH.C# 
JUC# 

TEACH 


x 


OGRADES.Grade#'F O(STUDENT.Sname='John Doe’) 


GRADES STUDENT 
10.5. 

With S in the outer loop and R in the inner loop, the number of disc 
accesses is 1700. If only one buffer is used for R, and the number of 
buffers for S is increased to 6, then the number of disc accesses can 


be trimmed down to 1417. 


10.7. Given R(A,B,C), S(B,C,D) and T(C,D,E). 
(i) Ox-b(tasc(RX{S) a) Ttasc(RIT)) 


Optimized version required response 


N 


x 


OB=b 


JUBC JUC 


RSRT 
(ii) vasc( Os-b(taBR ) tan) . Ttasc(Op=a(RXIT))) 


required response 
Xlasc 


Optimized version required response 


(iii) Téc(Oa=aOd-s0z=(RMISMIT) 


required response 


JUC 


WA=a 


RST 


Optimized version required response 


10.9. (i) 


required response 


JUEmp# 


OProject# = 'COMP353' 


ASSIGNED_TO 


(ii) required response 


Xl 


JUEmp# 


OProject# = 'COMP353' 


EMPLOYEE ASSIGNED_TO 


(iii) 


required response 


x 


IUProject# 


OProject.Name = ‘Database’ 


EMPLOYEE ASSIGNED_TO PROJECT 


(iv) required response 


x 


IUProject# 


O(Project# ='COMP353'V Project# ='COMP354') 


EMPLOYEE ASSIGNED_TO PROJECT 


(v) required response 


= JUEmp# 


IUProject# 


OEmp# = 107 


ASSIGNED_TO ASSIGNED_TO 


(vi) required response 


JUEmp# JUEmp# 


L_} OProject# = 'COMP453' 


ASSIGNED TO ASSIGNED TO 
(vii) required response 


HU) + OOOO 


TUProject# 


ASSIGNED PROJECT 


(viii) required response 


x JUEmp# 


JUProject# 


OrEmp# =107 


ASSIGNED_TO ASSIGNED_TO 


11. Recovery 


A computer system is an electro-mechanical device subject to 
failures of various types. The reliability problem of the database 
system is linked to the reliability of the computer system on which it 
runs. In this chapter we will discuss the recovery of the data 
contained in a database system following failures of various types. 
We will include the type of failures that have to be considered from 
the point of view of providing a reliable system and present the 
different approaches to database recovery. The types of failures that 
the computer system is likely to be subjected to include failures of 
components or subsystems, software failures, power outages, 
accidents, unforeseen situations, and natural or man-made disasters. 
Database recovery techniques are methods of making the database 
fault-tolerant. The aim of the recovery scheme is to allow database 
operations to be resumed after a failure, with minimum loss of 
information, at an economically justifiable cost. We will concentrate 
on the recovery of centralized database systems in this chapter; the 
recovery issues in a distributed system are presented in chapter 13. 


Solution to selected exercises 


12. Concurrency Management 


Concurrent execution of a number of transactions implies that 
the operations from these transactions may be interleaved. This is not 
the same as serial execution of the transactions where each 
transaction is run to completion before the next transaction is started. 
Concurrent access to a database by a number of transactions requires 
some type of concurrency control to preserve the consistency of the 
database, to ensure that the modifications made by the transactions 
are not lost, and to guard against transaction reading data that is 
inconsistent. The serializability criterion is used to test whether an 
interleaved execution of the operations from a number of concurrent 
transactions is correct or not. The serializability test consists of 
generating a precedence graph from a interleaved execution 
schedule. If the precedence graph is acyclic, then the schedule is 
serializable, which means that the database will have the same state 
at the end of the schedule as some serial execution of the 
transactions. In this chapter, we introduce a number of concurrency 
control schemes. 


Solution to selected exercises 


13. Database Security, 
Integrity & Control 


Security in database involves both policies and mechanisms 
to protect the data in the database and ensure that the data is not 
accessed, altered or deleted without proper authorization. Integrity 
implies that any properly authorized access, alteration or deletion of 
the data in the database does not change the validity of the data. 
Security and integrity concepts, though distinct, are related. The 
implementation of both the security and integrity requires that certain 
controls in the form of constraints must be built into the system. The 
DBA, in consultation with the security administrators, specifies these 
controls. The system enforces the controls by monitoring the actions 
of the users of the database and limiting their actions within the 
constraints specified for them. 


Solution to selected exercises 


14. Database Design 


Database design process is an iterative process. A number of 
design methodologies have been developed for use in the process. 
This chapter offers an informal discussion of the steps involved in 
designing a database. 


Solution to selected exercises 


15. Distributed Databases 


In this chapter we present distributed database systems. A 
distributed database can be defined as consisting of a collection of data 
with different parts of it being under control of a separate DBMS, running 
on an independent computer system. All such computers are interconnected 
and each system has autonomous processing capability, serving local 
applications. Each system participates, as well, in the execution of one or 
more global applications. Such applications require data from more than 
one site. 


Solution to selected exercises 


16. Current Topics in 
Database Research 


In this chapter we present some highlights of the recent 
advances in database system. The approach used is informal and 
intuitive. We discuss knowledgebase systems, logic databases, expert 
systems and the object oriented approach. 


Solution to selected exercises 


17. Database Machines 


In this chapter we discuss a number of approaches used to 
relieve the main computer system of the burden of running the 
database management system and handling the superfluous data not 
required for deriving the response of a user's query. 


Solution to selected exercises 


Appendix: CopyForward 


This document in electronic form, bearing a CopyForward permission, 
could be used for personal use and/or study, free of charge. Anyone could 
use it to derive updated versions. The derived version must be published 
under CopyForward. All authors of the version used to derive the new 
version must be included in the updated version in the existing order, 
followed by name(s) of author(s) producing the derived work. 


Such derived version must be made available free of charge in electronic 
form under CopyForward. Any other means of reproduction requires that 
annual profits(income minus the actual production costs) should be shared 
with established charitable organizations for children. This annual share 
must be at least 25% of the profits and the organization being supported 
must have a very modest administrative charges(20-30% of their annual 
budget). The 25% of the profits is the minimum and the original creator of 
the digital content may increase it to up to 40%. The derived contents 
would be governed by the term of the original creator of contents. 

Readers who found a CopyForward content or any derived work useful are 
encouraged to also make a donation to their favourite children charity. 
Make sure to choose charity which has very modest administrative charges 
or some deserving children in your community. 

This children’s charity contribution requirement of CopyForward is civil 
and moral! It would be judged in the court of public opinion. 


Why yet another intellectual rights protection? 


There are number of other copy permission other than the traditional 
copyright. With electronic contents it and software has become difficult to 


enforce copyright. Software has been opened up under some version of the 
copyleft (GNU GPL1). Another licensing arrangement is the open source 
licence2 3. Yet another version of copyright is the Creative Commons(CC) 
license. As in CopyForward, CC allows the creator to share, use, and 
building upon the CCed work but does not allow commercialization. 


The document outlining copyleft is over a hundred page long as opposed to 
CopyForward which is just the para given above. 


To the knowledge of the author, there have been no monetary claim 
litigations regrading the above new forms of copy protection licences. 
However, looking at the tech-giants that have emerged over the last few 
decades, they have taken something that was considered open4 and have 
created monopolies, concentration of market shares and deter the creation 
of alternatives. The types of mobile phones and the number of operating 
systems is an example5. These new tech-barons do not pay a fair percent of 
their income and none on the accumulated wealth; in this way they keep 
enriching themselves. 

While there is a move to limit the wealth as outlined in Limitarianism6 the 
success of even timid moves to impose a minimum income and wealth tax 
rate is hardly sufficient. 


How will CopyForward change? 


The author’s intent to publish this and other works under CopyForward is 
to allow the sharing of his effort and with the hope that even if there is 
commercialization, there is a moral and civic obligation that an appreciable 
part of the earnings would go to charitable causes for the next generation. 
It is hoped that if this charitable sharing of profits is not honoured, the 
public would boycott such commercialization. This is the only effective 
remedy for greed that exploits others’ labour for obscene personal 
enrichment7. 
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1 https://copyleft.org/ 


2 https://opensource.org/licenses 


3 https://en. wikipedia.org/wiki/Open-source_license 


4 https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a-mainframe- 
a-gator-and-three-dedicated-researchers/ 


5 Richard Jensen, Unix at 50: How the OS that powered smartphones started from 
failurehttps://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts-with-a- 
mainframe-a-gator-and-three-dedicated-researchers/ 


6 Ingrid Robeyns, Why Limitarianism? https://onlinelibrary.wiley.com/doi/ 
full/10.1111/jopp.12275 


7 Bipin C. Desai. Colonization of the Internet, IDEAS '21: Proceedings of the 25th 
International Database Engineering & Applications Symposium, https:// 
doi.org/10.1145/3472163.3472179 


